In the area of digital systems, the task of accommodating increasing bus traffic continues to pose a challenge. The primary bottle-neck in most bus transactions appears to be the system bus. The system bus is a bottle-neck primarily because many devices share the same bus and must contend for its resources.
The PCI bus is a high performance, 32-bit or 64-bit bus with multiplexed address and data lines which can accommodate multiple high performance peripherals. The PCI Bus supports burst modes in which a bus transaction may involve an address phase followed by one or more data phases in tandem with a command phase followed by one or more byte enable phases. As such, an external device may require the use of the bus for multiple clock cycles during a bus transaction which can exacerbate bottle-neck problems associated with a system bus. Reference is now made to FIG. 1 which illustrates an overview of a computer system that utilizes the PCI bus. In FIG. 1, computer system 100 comprises host CPU 101, host memory 102, peripheral hardware controller 103, and bridge device 105. Peripheral hardware controller 103 is coupled to host CPU 101 and host memory 102 through PCI bus 104. More particularly, peripheral hardware controller 103 provides an interface between PCI bus 104 and external devices such as disk drivers, display monitors, parallel data port, local area network, wide area network, or the like.
In general, host CPU 101 and external devices may take turns controlling PCI bus 104 in carrying out transactions such as read and write transactions. While a device which takes control of PCI bus 104 to initiate the transaction is known as a "bus master" device, a device at the other end of the transaction is known as a "bus target" (or "slave") device. Information that are involved in bus transactions between devices include data, address, commands, byte enables, and identification of bus master and bus target device.
While a bus may be synchronous or asynchronous, PCI bus is a synchronous bus. In other words, information flowing from the bus master device to the target device and vice versa are synchronized to a system clock such that a bus transaction must take place in an integral number of synchronized clock cycles. In carrying out bus transactions, bus protocols must be followed. These protocols consists mainly of bus mastership, requests for read or write transactions, and acknowledgment of such requests. PCI bus protocols can be found in "The PCI Local Bus Specification Rev 2.0", published by the PCI Special Interest Group, P.O. Box 14070, Portland, Oreg. 97214 and incorporated herein by reference.
Required tasks associated with synchronous PCI bus transactions such as address decoding, command decoding, and request acknowledgment must be generated based on the system clock. As a result, acknowledgement by a bus target takes more than one system clock cycle to generate following a bus transaction (read or write) request by a bus master. After a bus master requests a bus transaction requiring one clock cycle, an additional clock cycle may be required for address and command decoding. For example, a bus master may send a bus transaction request and related information (i.e., address and command) to a bus target during a first clock cycle, a bus target receives the information and performs the necessary tasks of address and command decoding during a second clock cycle. The bus target then generates an acknowledgement during a third clock cycle. The use of three clock cycles slows down the bus transaction as a result.
Another challenge presented by the PCI bus involves a requirement for zero nano-second hold time. To allow sufficient time for information related to a bus transaction (i.e., command, address, and data) to arrive at a destination, the "PCI Local Bus Specification" allows a set-up time, t.sub.su, of up to 7 nano-seconds from the time a bus transaction signal indicating the start of an information phase (e.g., address, data, command, etc.) is asserted until the next clock cycle begins. Moreover, once bus transaction information is made available, the "PCI Bus Specification" allows zero nano-second hold-time, t.sub.h, for a device to acquire bus transaction information until the beginning of a next clock cycle. The failure to meet the zero-hold time requirement may lead to the capturing of invalid bus transaction information since a different information phase may begin in the following clock cycle. In other words, the zero nano-second hold-time requires bus transaction information to be preserved during the clock cycle in which that particular bus transaction information is put on a system bus.
Referring now to FIG. 2 which is a timing diagram illustrating set-up time, t.sub.su, and hold-time, t.sub.h. In FIG. 2, during clock cycle 1, signal FRAME# is asserted indicating a bus transaction request and the start of an address and command phases. However, required processing time may cause signal FRAME# to be asserted approximately at a middle part of clock cycle 1. At this point, bus transaction information (i.e., address and command) is made available on a system bus. Bus transaction information is to be available by t.sub.su before the next rising clock edge. Once the transaction information is made available, more than zero nano-seconds is needed to properly acquire the bus transaction information. As a result, the zero nano-second hold-time requirement as currently imposed by the "PCI Local Bus Specification" is unresolved.